Brokering SDO data in an SBO
The SBO acts as an intermediary for all data in its SDOs. It serves as a Data-Source for client-side SmartObjects requesting a variety of data that it can provide. When you use it in another container, such as a SmartWindow, you can link visual objects, such as browsers and viewers, to it. If you make a Data link from the SBO to such a Data-Target, then at run time the SBO examines the Signature property of the Data-Target and compares it to the Signature of the SDOs. The ContainedDataColumns SBO property, a delimited list of all DataColumns in the SDOs, is initialized at startup time by the SBO to assist in this. At run time the client-side SBO is responsible for brokering data to and from the visual objects that are linked to it.
In the case of browsers, the SBO provides the browser with the handle of the SDO query it needs to browse (using the getDataHandle function). The ObjectMapping SBO property is built up as browsers are connected to the SBO at run time, to keep track of the SDO queries the browsers are attached to.
During the initialization of the SBO, other client objects linked to the SBO are added to the ObjectMapping property. A viewer is mapped to the SDOs that provide the fields it displays and updates. Likewise, the SBO matches any browsers that are Data-Targets of the SBO with the appropriate SDO’s temp-table based on matching field/column names. A Navigation-Source (Toolbar band) can specify in its property dialog box which SDO should be the Navigation-Target for its event messages. This SDO is also added to the ObjectMapping property.
Navigation-Sources must also specify which SDO should respond to the Navigation events. The default is the MasterDataObject, but if this is not the SDO you want, then you must choose the SDO ObjectName in the Instance Property dialog box of the SmartToolbar, as shown in Figure 11–6. Access this dialog box from the Container Builder by choosing the Properties button, or from a static SmartWindow as you would any property sheet.
In the case of viewers and other objects that request and display individual fields from the current row, the SBO provides those values by requesting them from one or more contained SDOs and passing them on. The API for these calls is the same as in SDO connections (including the published dataAvailable event and the colValues function). For example, an SBO containing a Customer SDO and an Order SDO can feed data to a Customer SmartDataViewer showing the selected Customer, and also to an Order browser showing all retrieved Orders of the currently selected Customer. You can also build a SmartDataViewer against the SBO itself rather than against one of the SDOs. It can request fields from more than one contained SDO. If you build a viewer against an SBO, the viewer wizard displays columns from all contained SDOs, qualified by the SDO ObjectName, to allow the user to chose fields from multiple SDOs. When the viewer is built against an SBO in this way, each frame field in the viewer itself will have its SDO’s ObjectName as a table-name qualifier (rather than RowObject), to allow the SBO to determine which SDO should supply the requested column values. Otherwise, if a viewer is used that you built against one of the contained SDOs, its field names have the standard RowObject qualifier, and in that case the SBO matches the requested column list against its ContainedDataColumns to identify the matching field (the first match is taken).